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Abstract 

This  report  outlines  the  work  carried  out  on  Air  Force  funded  activities  within  our 
research  group  aimed  at  developing  a  prototype  ad-hoc  network  using  commercial  off- 
the-shelf  technology  that  will  allow  users  of  handheld  computers  equipped  with  wireless 
interfaces  to  use  common  networked  multimedia  applications.  The  report  summarises  the 
main  stages  of  the  project  and  concludes  with  some  thoughts  on  promising  future 
directions. 

1.  Introduction 

Ad-hoc  networks  are  networks  where  there  is  no  fixed  structure.  Each  node  in  the 
network  may  act  like  a  switch,  forwarding  on  data  to  another  node.  Since  there  is  no 
central  controlling  point,  such  as  a  base  station  at  the  centre  of  a  cell  in  a  mobile  phone 
network,  there  is  no  central  point  of  failure.  The  distributed  nature  of  such  a  network  give 
the  effect  of  a  network  that  ‘manages  itself,  allowing  nodes  to  join  and  leave  the  network 
at  any  time  and  allowing  all  nodes  on  the  network  to  communicate  with  each  other.  Some 
nodes  on  the  ad-hoc  network  may  act  as  gateway  nodes  to  the  Internet  or  to  the  PSTN, 
allowing  all  users  on  the  network  Internet  and  normal  telephone  services. 

The  aim  of  this  project  was  to  develop  an  ad-hoc  network  that  was  easily  deployable  and 
could  be  connected  to  a  fixed  network  via  a  gateway  node  in  the  network.  In  particular 
the  project  proposal  listed  review,  evaluation  and  adaptation  of  existing  wireless  link  and 
network  protocols  as  the  main  focus  of  work.  The  project  did  in  fact  go  beyond  these 
original  plans  and  an  extremely  flexible  ad-hoc  network  was  designed. 

2.  Project  Milestones 

As  stated  in  the  introduction  the  main  work  in  the  project  proposal  was  a  review, 
evaluation  and  adaptation  of  existing  wireless  link  and  network  protocols  so  that  suitable 
software  could  be  developed  the  ad-hoc  network.  The  results  of  this  investigation  were 
presented  in  the  second  interim  report  and  will  not  be  repeated  here.  It  was  also 
necessary  to  develop  a  hardware  platform  on  which  the  software  would  run.  In  designing 
and  developing  a  suitable  software  and  hardware  architecture  the  project  followed  a 
number  of  distinctive  phases. 
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2.1  Initial  Solution 

When  the  work  on  the  project  began  it  was  planned  to  concentrate  on  the  routing 
protocols  and  to  use  off-the-shelf  radios  for  the  nodes  of  the  ad-hoc  networks.  It  was 
decided  to  implement  the  network  at  amateur  radio  frequencies.  Figure  1  shows  an 
example  node  of  these  ad-hoc  networks. 
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Ad-hoc  Network  Node  Phase  1 
Figure  1 


2.2  Revised  Solution 

It  became  clear  that  the  proposed  hardware  and  software  architecture  was  very 
cumbersome  and  a  totally  new  software  and  hardware  ad-hoc  architecture  was  designed. 
The  new  platform  still  used  off-the-shelf  components  but  was  cheaper  and  far  more 
flexible. 

The  phase  2  ad-hoc  node  consisted  of  a  radio  and  a  handheld  device.  The  radio  consisted 
of  40  kbit/s  UHF  radios  developed  by  the  project  team.  The  principal  advantage  to  using 
a  custom  built  radio  was  that  it  allowed  our  project  team  to  have  complete  control  over 
packet  formats,  media  access  control  etc  rather  than  attempting  to  run  ad-hoc  networking 
protocol  on  top  of  protocols  built  into  the  radio  hardware. 

The  handheld  device  was  a  HP  PDA  running  Windows  CE.  The  radio  circuit  together 
with  the  power  supply  had  approximate  dimensions  2cm  x  8cm  x  6cm  and  could  be  fixed 
easily  to  the  back  of  the  handheld  device.  The  HP  PDA  communicated  with  the  radio  via 
the  serial  port.  Figure  2  shows  an  early  prototype  of  the  ad-hoc  network  node. 


Ad-hoc  Network  Node  Phase  2 
Figure  2 


A  highly  modular  layered  framework  was  designed  to  cater  for  the  software  that  was 
needed  on  each  node  of  the  ad-hoc  network.  Each  node  of  the  network  had  its  own  stack; 
the  layers  of  the  stack  consist  of  the  appropriate  building  blocks  such  as  an  ad-hoc  routing 
block  or  an  encryption  block.  A  ‘generic  layer’  interface  that  allows  the  dynamic 
assembly  of  a  stack  was  created.  The  multi-threading  and  synchronisation  facilities 
available  in  the  handheld  device  environment  were  used  to  design  this  generic  layer 
architecture.  Each  layer  runs  as  an  independent  thread  and  interacts  with  its  neighbouring 
layers  in  very  simple,  clearly  defined  ways.  The  set  of  layers  is  assembled  at  runtime  to 
form  a  complete  protocol  stack.  Figure  3  shows  a  schematic  of  three  nodes  of  an  ad-hoc 
network  with  the  appropriate  layers  on  each  node  of  the  network. 
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Ad-hoc  network  Layered  Architecture 
Figure  3 


The  wireless  node  has  a  layer  for  controlling  the  radio,  onto  which  can  be  placed  a  variety 
of  media  access  control  and/or  network  routing  protocols.  Our  main  implementation 
within  this  project  used  an  on-demand  Ad-Hoc  network  routing  protocol  called  Dynamic 
Source  Routing  (DSR)  and  in  the  future  we  are  planning  to  augment  this  with  a  range  of 
different  protocols  such  as  the  Zone  Routing  Prototocol  (ZRP)  and  a  variation  of  the 
piconet  protocol  used  in  the  Bluetooth  system. 

Irrespective  of  which  networking  protocol  is  in  use,  a  variety  of  application  and 
application-support  layers  can  be  placed  on  top  of  the  lower  part  of  the  stack.  Figure  3 
shows  an  encryption  layer  (implementing  the  Blowfish  algorithm)  and  an  application 
layer  (e.g.  WWW  access_.  The  gateway  node  allows  access  to  a  fixed  network  via  the 
relay  layer.  The  gateway  node  also  has  software  for  controlling  the  radio  as  well  as  what 
we  term  a  datagram  layer.  This  datagram  layer  is  based  on  the  use  of  sockets  and  allows 
communication  across  the  fixed  network.  It  also  enables  the  simulation  of  physical  media 
such  as  radio  broadcasting  and  IrDA,  by  configuring  a  node  sockets  appropriately. 

2.3  Advanced  Solution 

In  the  third  phase  of  the  project  the  ad-hoc  node  was  further  improved.  The  radio  circuit 
was  advanced.  The  software  was  ported  to  a  Pocket  PC.  The  Pocket  PC  is  a  more 
powerful  device  and  supports  multimedia  applications.  In  this  stage  of  the  project  a  large 
number  of  extra  layers  (e.g.  for  error  checking  and  encryption)  were  developed  and  the 
chosen  ad-hoc  routing  protocol  is  use  was  streamlined.  Figure  4  shows  the  latest  ad-hoc 
network  node. 


Ad-hoc  Network  Node  Phase  3 
Figure  4 


3.  Conclusions 

The  ad-hoc  network  designed  over  the  duration  of  this  project  proved  to  be  successful. 
The  nodes  of  the  network  are  light  and  small.  The  software  at  each  node  is  flexible  and 
easily  configurable.  The  system  allows  for  easy  testing  of  a  variety  of  network  routing 
protocols  of  interest.  Internet  access  is  available  to  all  nodes  in  the  network  via  the 
gateway  node.  This  has  been  extensively  tested.  Streaming  audio  has  also  been  tested  on 
the  network. 


4.  Future  Work 


Within  the  scope  of  this  project,  we  have  developed  a  test-bed  system  that  allows  a 
variety  of  ad-hoc  protocols  to  be  easily  built  and  deployed  in  a  real  wireless  network.  We 
intend  to  use  this  test-bed  to  provide  new  insights  into  the  properties  of  existing  ad-hoc 
protocols  and  to  assist  us  in  the  design  of  hybrid  and  totally  new  protocols  addressing  this 
area. 

We  have  developed  a  number  of  very  simple  applications,  and  in  the  future,  we  would 
like  to  add  to  this  list.  In  particular,  we  would  like  to  develop  a  general  purpose  one-to- 
one  and  many-to-many  voice  conferencing  system,  which  coupled  with  the  appropriate 
group  security  mechanisms  would  function  as  an  extremely  flexible  field 
communications  system.  Other  application  areas  that  we  will  pursue  involve  new 
approaches  to  group  broadcasting  and  position-aware  applications. 
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Abstract 

We  present  progress  towards  building  a  test-bed  allowing  the  use  of  multimedia 
applications  (e.g.  web  access,  voice  telephony)  running  on  commercial  handheld  and 
palmtop  PCs.  The  handheld  units  communicate  with  each  other  and  with  the  fixed  IP 
network  using  an  ad-hoc  networking  protocol  derived  from  the  Dynamic  Source  Routing 
(DSR)  algorithm  running  on  simple  short-range  radio  modules  developed  by  the  project 
team.  We  review  the  main  features  of  existing  ad-hoc  protocols,  and  go  on  to  describe 
both  the  existing  protocol  implementation  based  on  DSR  and  also  the  future  direction  of 
our  protocol  development  effort. 


2.  Introduction 

This  report  outlines  progress  on  Air  Force  funded  activities  within  our  research  group 
aimed  at  developing  a  prototype  ad-hoc  network  using  commercial  off-the-shelf 
technology  that  will  allow  users  of  handheld  computers  equipped  with  wireless  interfaces 
to  use  common  networked  multimedia  applications. 

A  major  goal  of  the  project  is  to  develop  a  test-bed  that  we  can  use  to  realise  our  new 
designs  for  ad-hoc  networking  protocols  and  to  make  comparisons  between  new  and 
existing  protocols.  We  have  made  considerable  progress  on  this  and  we  present  an 
outline  of  the  test-bed  in  the  following  sections,  before  detailing  progress  on  the  design 
and  development  of  an  ad-hoc  protocol  derived  from  the  Dynamic  Source  Routing 
protocol.  Finally  we  review  the  direction  of  the  project  and  discuss  the  work  that  will  be 
carried  out  in  the  time  remaining. 

2.  Test-bed  Architecture 

Our  research  group  has  interests  spanning  the  entire  range  of  topics  within  wireless 
communications,  from  the  use  of  novel  mobile  aware  applications  to  routing  protocol 
design  through  to  the  development  of  adaptable  software  radios.  In  developing  a  test¬ 
bed,  we  needed  to  develop  a  highly  modular  layered  framework  that  would  allow  entire 
building-blocks  (e.g.  the  radio  subsystem,  the  ad-hoc  networking  protocol  or  the 
application  layer)  to  be  assembled  to  fit  the  problem  at  hand. 


We  achieved  this  by  building  a  ‘generic  layer’  interface  that  allows  the  dynamic  assembly 
of  a  stack  consisting  of  hardware  and  software  elements.  This  allows  us  to  develop,  for 
instance,  a  range  of  ad-hoc  networking  modules  that  can  be  debugged  using  an  emulated 
broadcast  network  implemented  on  a  segment  of  Ethernet,  later  field  tested  on  a  real  radio 
link  and  finally  operated  across  a  radio  link  implemented  using  software  radio  techniques. 

2.1  Software 

We  are  targeting  our  software  to  run  on  commodity  desktop  workstations  and  handheld 
computers  running  either  Microsoft  Windows  NT  or  Windows  CE  and  thus  our 
programming  support  environment  is  based  on  Win32.  Using  the  multi-threading  and 
synchronisation  facilities  available  in  this  environment,  we  have  designed  a  generic  layer 
architecture  where  each  layer  runs  as  an  independent  thread  and  interacts  with  its 
neighbouring  layers  in  very  simple,  clearly  defined  ways.  A  typical  layers  might 
implement  an  ad-hoc  routing  protocol,  a  WWW-proxy  application  or  an  emulated  radio 
network  layer.  Our  software  radio  will  be  realised  by  combining  a  sequence  of 
‘transformer’  layers  that  will  each  carry  out  a  single  well-defined  signal  processing 
operation  on  the  data  passing  through. 


Figure  1:  Some  typical  layers  and  the  interchange  of  a  real  and  software  radio 

modules 


Figure  1  shows  a  typical  set  of  layers,  each  implemented  independently  and  then 
assembled  at  runtime  to  form  a  complete  protocol  stack.  The  diagram  also  shows  how  a 


layer  representing  a  real  433MHz  radio  can  be  swapped  out  and  replaced  with  a  stack 
implementing  part  of  the  radio  in  software. 

2.  2  Hardware 

The  nodes  in  an  Ad-hoc  network  must  be  lightweight  and  portable  but  at  the  same  time 
be  capable  of  performing  significant  processing.  For  these  reasons,  we  are  using  Hewlett 
Packard  Windows  CE  based  machines  (in  both  handheld  and  palmtop  formats)  as  the 
main  nodes  in  our  network.  Figure  2  shows  two  samples  of  these.  The  machines  are 
based  on  Hitachi  SH3  RISC  processors  and  are  equipped  with  RS-232  interfaces  and 
audio  hardware  -  which  makes  them  ideal  for  our  purposes. 

They  are  programmed  using  the  Win  32  API  with  which  we  have  considerable  expertise. 
We  expect  that  all  of  our  software  and  hardware  will  migrate  easily  to  the  next  generation 
of  Pocket  PCs  when  these  become  available.  The  use  of  Win  32  also  allows  us  to  use  the 
richer  development  environment  of  Windows  NT  and  Windows  2000  for  the  bulk  of  the 
initial  testing. 


Figure  2:  Target  Hardware  —  Commodity  Windows  CE  machines  in  Handheld  and 

Palmtop  formats 


The  PDAs  are  equipped  with  low  powered  40  kbit/s,  433  MHz  radios  developed  by  the 
project  team.  The  radio  circuit  together  with  the  power  supply  has  approximate 
dimensions  2cmX8cmX6cm  and  can  be  fixed  easily  to  the  back  of  the  handheld  device. 
The  HP  PDA  communicates  with  the  radio  via  the  serial  port.  Figure  3.  shows  the  radio 
subsystem  in  prototype  form. 


Figure  3:  An  Early  Prototype  of  the  Radio  Subsystem 


While  it  is  not  an  integral  part  of  this  project,  work  on  the  design  of  low  profile  antennas 
for  use  with  this  system  is  also  taking  place. 


3.  Review  of  existing  Ad-Hoc  Protocols 

Ad-hoc  routing  protocols  can  be  divided  up  into  two  distinct  categories,  proactive  (or 
table  based)  routing  and  reactive  (or  on-demand)  routing  strategies.  Proactive  strategies 
try  to  maintain  an  up  to  date  routing  table  in  each  node  at  all  times  whereas  reactive 
strategies  only  create  routes  on  demand.  Some  protocols,  such  as  the  Zone  Routing 
Protocol,  are  explicit  hybrid  proactive/reactive  systems  that  route  to  near  by  nodes  with  a 
proactive  strategy  and  to  distant  nodes  with  a  reactive  strategy. 

Ideally,  an  ad-hoc  network  will  have  maximum  connectivity  and  throughput  between 
nodes  with  a  minimum  of  signalling  overhead.  There  are  many  more  factors  which  are 
important  in  describing  an  ad-hoc  network.  These  factors  include  link  capacity  (bits  per 
second  between  nodes),  network  size  (number  of  nodes),  network  connectivity  (average 
degree  of  a  node),  topological  rate  of  change  (modes  moving  around  a  lot  or  staying  in 
one  place  for  a  long  time),  fraction  of  unidirectional  links,  traffic  patterns  and  type 
(bursty  web  traffic,  periodic  sensor  data,  voice  or  multimedia  streams,  multicast  traffic) 
and  sleeping  patterns  (battery  conservation  issues).  Depending  on  the  values  of  these 
factors,  some  routing  algorithms  will  under  certain  network  conditions  be  more  efficient 
than  others. 


Listed  here  are  short  summaries  of  some  of  the  more  popular  ad-hoc  routing  protocols. 

ABR  -  Associativity  Based  Routing 

•  On  demand  source  routing 

•  ABR  tries  to  derive  longer-lived  routes 

•  Each  node  periodically  beacons.  Receiving  nodes  increment  associativity  tick 
counters  with  respect  to  transmitting  node.  A  high  number  of  ticks  mean 
stable/long  lived  connection. 

SSA  -  Signal  Stability-based  Adaptive  Routing 

•  On  demand  source  routing 

•  Similar  to  ABR;  it  tries  to  find  most  stable  network  routes 

•  The  selection  of  route  is  based  on  signal’s  strength  and  a  nodes  ‘stability’  (ie.  it 
isn’t  moving  about  quickly  breaking  links). 

DSDV  -  Dynamic  Destination-sequenced  Distance-vector  Routing  protocol 

•  Table  based  routing 

•  Each  node  maintains  a  full  table  of  all  available  destinations,  number  of  hops  to 
destination  and  a  sequence  number  assigned  by  the  destination 

•  Routes  with  the  highest/most  recent  sequence  numbers  are  used 

•  Tables  are  periodically  shared  with  neighbours  and  sometimes  a  ‘full  dump’  may 
take  place. 

WRP  -  Wireless  Routing  Protocol 

•  Table  based  routing 

•  Every  node  maintains  a  distance  table,  routing  table,  link-cost  table  and  message 
retransmission  list 

•  Routing  tables  are  exchanged  with  neighbours  periodically  and  upon  link  changes. 

RDMAR  -  Relative  Distance  Micro-Discovery  Ad  Hoc  Routing  Protocol 

•  On  demand  source  routing 

•  RDMAR  localizes  query  flooding  by  knowing  the  relative  distance  (RD)  between 
two  terminals 

•  RD  =  last  RD  value  +  average  nodal  mobility  +  time_last_communicated 

CBRP  -  Cluster  Based  Routing  Protocol 

•  Based  on  source  routing 

•  CBRP  uses  a  hierarchical  topology  that  may  scale  better  that  flat  network 

•  Groups  of  nodes  elect  cluster  heads.  The  groups  maintain  neighbour  tables 
internally  and  the  cluster  heads  perform  source  routing  to  other  cluster  heads. 

AODV  -  Ad  hoc  On-demand  Distance  Vector  Routing 

•  On  demand  source  routing 

•  Not  unlike  an  on  demand  version  of  DSDV 

•  Destination  Sequence  Numbers  are  maintained  for  each  route  entry.  DSNs  are 
exchanged  using  periodic  HELLO  messages. 


•  DSNs  ensure  loop-free  routing 

DSR  -  Dynamic  Source  Routing 

•  On  demand  source  routing 

•  Routes  formed  purely  on  demand  -  no  periodic  broadcasts 

•  In  lower  traffic  situations  DSR  is  efficient  do  to  less  signaling  overhead. 

ZRP  -  Zone  Routing  Protocol 

•  Hybrid  on-demand  reactive  and  table  driven  proactive  routing 

•  Proactive  routing  in  ‘local’  area  or  ‘zone  radius’  (max  number  of  hops  from  a 
node). 

•  Beyond  local  radius  it  becomes  inefficient  to  maintain  full  routing  tables  (too 
much  data,  to  many  updates  mean  high  signaling  overhead)  so  ‘bordercasting’ 
mechanism  propagates  route  queries  though  the  rest  of  the  network. 

•  Zone  radius  can  be  adjusted  to  give  optimal  performance. 

Another  important  metric  when  deciding  which  ad-hoc  routing  protocol  to  choose  is  ease 
of  implementation.  Many  of  the  more  complex  protocols  are  optimized  for  a  particular 
mobility  or  node  distribution  scenario.  We  are  primarily  interested  in  having  a  robust 
core  protocol  that  works  realonably  well  in  many  different  situations  and  can  be  extended 
in  the  future.  The  Dynamic  Source  Routing  protocol  was  chosen  as  our  initial  base  as  it 
was  one  of  the  more  simple  and  straightforward  routing  protocols. 


4.  Implementation 
4.1  DSR  Implementation 

The  routing  algorithm  that  we  implemented  as  a  component  of  the  software  stack  is  an 
improved  version  of  standard  Dynamic  Source  Routing  (DSR)  protocol.  As  with  all  ad- 
hoc  protocols  it  allows  nodes  to  discover  a  route  across  multiple  network  hops  to  any 
destination  in  a  mobile  network.  DSR  is  just  one  of  many  ad-hoc  routing  algorithms 
mentioned  in  the  review  of  existing  ad-hoc  protocols  above. 

DSR  is  an  on-demand  protocol  that  reacts  to  a  specific  demand  to  dynamically  establish  a 
route  from  one  node  to  another,  unlike  table-driven  protocols  that  try  to  ensure  that  all 
nodes  maintain  up  to  date  information  on  the  changing  topology  of  the  network.  When 
the  source  node  receives  a  demand  to  route  data  to  a  target  node  a  route  request  floods  the 
network  seeking  the  target  node.  As  the  route  request  propagates  through  the  network  it 
appends  the  address  of  every  node  through  which  it  passes.  When  the  route  request 
reaches  the  target  node  a  route  reply  is  then  sent  back  to  the  source  node  along  the  route 
through  which  the  successful  route  request  had  been  propagated.  When  the  source  has 
received  the  route  reply  it  may  then  attempt  to  route  all  the  data  using  the  route  contained 
in  the  route  reply. 

In  the  standard  implementation  of  DSR,  intermediate  hops  are  not  required  to  maintain 
routing  information  in  order  to  route  data  packets  as  all  the  routing  information  is 


contained  in  the  header  of  the  packets  being  routed.  As  the  intermediate  hops  are  not 
relied  upon  to  provide  this  routing  information  during  the  data  routing  phase,  the  need  for 
periodic  router  advertisements  that  update  nodes  on  the  status  of  the  network  topology,  is 
eliminated,  reducing  the  overhead  of  this  algorithm.  If  it  happens  that  a  route  becomes 
invalid  owing  to  the  inherent  changing  topology  of  the  mobile  network  then  a  new  route 
request  can  be  originated  to  establish  a  fresh  route  to  the  target.  The  DSR  algorithm 
makes  use  of  lightweight  route  maintenance  procedures  that  are  not  as  extensive  or  as 
costly  as  those  employed  by  the  table-driven  protocols.  The  localised  use  of  route  error 
reporting  mechanisms  and  routing  acknowledgements  allows  for  essential  route 
maintenance  only.  The  failure  of  a  node  is  only  reported  to  those  nodes  directly 
concerned  with  the  routing  of  the  data  in  question. 

While  the  standard  DSR  algorithm  does  not  actively  engage  in  an  effort  to  maintain 
accurate  topology  knowledge  for  each  node  at  all  times,  there  are  certain  procedures  that 
can  be  implemented  to  utilise  existing  information  being  circulated  through  the  network 
in  an  attempt  to  increase  the  efficiency  of  the  algorithm.  Intermediate  nodes,  which  are 
otherwise  acting  as  packet  repeaters,  and  idle  nodes  that  are  within  broadcast  range  of  a 
transmitting  node,  can  eavesdrop  on  the  routing  information  contained  in  the  packets  that 
are  being  propagated  through  the  network.  Nodes  may  choose  to  eavesdrop  if  they  have 
the  power  capacity  to  do  non-essential  tasks  and  if  they  are  not  called  upon  to  process 
packets  that  are  actually  destined  for  them.  The  advantage  of  this  eavesdropping  is  that  if 
these  nodes  are  then  required  to  route  data  themselves,  they  may  have  already  cached  the 
appropriate  routes  during  this  eavesdropping  process,  eliminating  the  need  to  flood  the 
network  with  further  route  requests.  This  process  does  not  increase  the  overhead  of  DSR 
and  is  not  a  cause  of  network  congestion.  Whereas  table-driven  algorithms  involve  the 
use  of  separate  route  maintenance  and  data  routing  procedures,  the  algorithm 
implemented  here  makes  the  most  efficient  use  of  the  routing  information  and  bandwidth 
available  to  it.  While  this  does  not  ensure  that  each  node  has  a  comprehensive  knowledge 
of  all  routes  leading  from  it,  it  means  that  nodes  do  have  knowledge  of  those  local  routes 
that  are  actively  being  used  to  transmit  data. 

An  experimental  evaluation  environment  was  created  to  test  the  stability  and 
effectiveness  of  the  routing  protocol.  This  environment  consisted  of  both  mobile  and 
static  nodes.  The  DSR  protocol  was  implemented  in  such  a  way  that  it  could  be  used  and 
tested  over  various  physical  layers,  whether  real  or  simulated.  A  ‘datagram’  layer,  based 
on  the  use  of  sockets,  enables  the  simulation  of  physical  media  such  as  radio  broadcasting 
and  IrDA,  by  configuring  a  node  sockets  appropriately.  Such  simulations  allow  for  the 
robust  testing  of  the  routing  protocol  before  field  trials  commence. 


4.2  Experimental  Setup 

The  in-house  designed  test-bed,  outlined  in  section  2,  is  used  to  evaluate  the  performance 
of  the  ad-hoc  network  routing  protocols  in  which  we  are  interested.  Figure  4  gives  an 
overview  of  the  current  test  scenario.  The  system  consists  of  a  wireless  ad-hoc  network 
that  contains  a  node  with  access  to  a  fixed  network.  This  is  typical  of  what  would  be 
expected  in  a  fully  functioning  ad-hoc  environment. 


Figure  4:  Experimental  Set-up  -  Scenario  1 

The  appropriate  layers  are  placed  in  each  node  of  the  network  and  assembled  at  runtime 
to  form  a  complete  protocol  stack.  The  layers  in  the  main  nodes  are  shown  in  Figure  5.  In 
the  wireless  ad-hoc  network  the  layers  of  the  communication  stack  consist  of  an 
application  layer,  an  encryption  layer  (blowfish),  an  ad-hoc  routing  layer  (DSR)  and  a 
radio  API  layer.  The  access  point  or  gateway  node  between  the  wireless  and  wired 
networks  contains  two  stacks.  Data  arrives  from  a  wireless  node  via  the  radio  API  layer 
and  passes  through  a  relay  layer  and  is  broadcast  to  the  fixed  network  through  the 
datagram  layer.  All  other  nodes  in  the  fixed  network  have  a  datagram  layer,  a  DSR  layer, 
a  blowfish  layer  and  some  have  application  layers. 


Figure  5:  Experimental  Set-up  -  Communication  Stacks  Details 

By  using  this  approach  we  can  assess  interaction  between  wireless  and  wires  nodes,  the 
protocol  performance  over  a  real  wireless  channel  as  well  as  having  the  option  of  greatly 
increasing  the  number  of  nodes  in  the  network  in  order  to  effectively  test  the  scalability 
of  the  DSR  protocol. 


4.3  Future  Work 


Presently,  we  have  constructed  a  working  wireless  ad-hoc  network  based  on  the  Dynamic 
Source  Routing  protocol.  In  the  remaining  months  of  the  project,  we  will  consolidate  and 
stabilize  this  work  as  we  enter  a  phase  where  we  can  experiment  with  the  protocol  in  a 
variety  of  mobility  scenarios. 

We  plan  to  extent  the  base  protocol  to  incorporate  some  of  the  features  found  in  other 
routing  protocols. 

These  features  may  include: 

•  Zone  Routing 

As  the  network  size  increases  some  form  of  balancing  the  useful  effects  of 
close  range  table  driven/proactive  routing  with  long  range  demand/reactive 
routing  may  lead  to  less  signalling  traffic  on  the  network  as  a  whole.  The 
approach  taken  by  ZRP  allows  a  radius  around  a  node  beyond  which  ZRP 
switches  from  a  proactive  to  reactive  routing  protocol. 


•  Signal  stability 

By  making  use  of  signal  level  readings  or  the  past  error  performance  of  links, 
we  may  be  able  to  determine  more  accurately  which  nodes  are  best  suited  for 
transit  routing.  Also,  by  using  associativity  parameters  such  as  ABR’s  ticks, 
nodes  that  are  ‘passing  though’  the  system  may  be  avoided  to  route  traffic 
though.  By  avoiding  these  transient  or  unstable  nodes  the  overall  signalling 
traffic  of  the  network  is  reduced. 

•  Forward  Error  Correction 

Small  amounts  of  Forward  Error  Correction  (FEC)  in  some  situations  will 
make  great  savings  on  wasted  retransmission  traffic.  We  will  implement  an 
FEC  module  for  our  stack  (“Smart  Reliability  Layer”)  to  help  alleviate 
retransmissions  due  to  simple  bit  errors  in  transmitted  packets. 

In  addition  to  our  experimentation  with  ad-hoc  protocols,  we  are  interested  in  exploring 
the  security  aspects  of  wireless  applications  that  will  run  on  ad-hoc  networks.  Whenever 
a  population  of  wireless  nodes  forms  an  ad-hoc  network,  this  necessarily  implies  the 
formation  of  an  ad-hoc  group  of  identities  that  must  be  mutually  authenticated  and 
dynamic  maintenance  of  this  networked  group.  We  would  also  like  to  pursue  the  use  of 
different  applications  that  can  profit  from  the  ad-hoc  nature  of  the  network. 


